ACH Payment Processing

ABSTRACT

Efficiently processing ACH payments by processing batches of ACH payments in parallel. A processing system of an ACH operator receives an ACH file including multiple batches of ACH items. Each batch includes at least one ACH item. A control module of the processing system organizes data in the ACH file into multiple partitions according to a selected strategy. Each partition includes at least one of the batches. A processing module of the processing system separately processes each partition in parallel, validating the batches and ACH items and creating at least one output batch for each partition. If the control module determines that the ACH file is acceptable, based on this parallel processing, then the processing module settles the ACH items in the output batches and creates at least one new ACH file for transmitting the settled ACH items to one or more corresponding receiving depository financial institutions.

TECHNICAL FIELD

The invention relates generally to processing payments in an AutomatedClearinghouse (“ACH”), and more particularly to efficiently processingACH payments by processing batches of ACH payments in parallel.

BACKGROUND

Financial institutions are increasingly clearing financial transactionsusing electronic systems such as the Automated Clearinghouse (“ACH”)network. The ACH network is a nationwide electronic funds transfersystem supported by several operators, including the Federal ReserveBanks and other institutions. The ACH network is governed by a set ofrules administered by the National Automated Clearinghouse Association(“NACHA”). ACH offers financial institutions, companies, consumers, andothers an efficient alternative to paper based payment methods.

In ACH, an originator sends electronic transaction items to anoriginating depository financial institution (“ODFI”). The originator isa person or organization that agrees to initiate ACH payments in the ACHnetwork according to an arrangement with another, receiving person orentity (a “receiver”). For example, the originator can be a company thatagrees to originate an ACH payment to an account of a consumer.

The ODFI packages the transaction items in one or more batched ACHfiles, according to the NACHA rules. The ODFI transmits the ACH files toan ACH operator. The ODFI may send the ACH files to the ACH operatordirectly or via a third party or “remote” sending point. The third partyor remote sending point may be a depository financial institution or acompany providing processing services for a depository financialinstitution. The term “ACH file” is used herein to refer to anycollection of batched and/or unbatched ACH transaction items.

The ACH operator is a Federal Reserve Bank or other entity that receivesACH files from an ODFI and distributes transaction items within the ACHfiles to at least one corresponding receiving depository financialinstitution (“RDFI”) associated with a receiver. In some cases, the ACHoperator also may perform settlement functions (crediting and debitingof accounts) for the affected financial institutions.

Each ACH file includes at least one batch of transaction items. Eachbatch includes one or more transaction items. The terms “transactionitem” and “ACH item” are used interchangeably herein to refer to anybatched electronic payment or payment instruction, whether internationalor domestic, and/or information associated with a batched electronicpayment or payment instruction. For example, a payment or paymentinstruction can be a credit, a debit, or a rejected or returnedtransaction.

Upon receiving an ACH file, processors of the ACH operator sort, batch,and re-assemble the transaction items in the ACH file in at least onenew ACH file for delivery to one or more RDFI's. The RDFI's may receivethe ACH files directly or via one or more third party or “remote”receiving points. Each third party or remote receiving point may be adepository financial institution or a company providing processingservices for a depository financial institution. The RDFI's forward thetransaction items in the ACH files to their corresponding receivers.Each receiver is a person or organization that has authorized anoriginator to initiate an ACH payment to an account of the receiver, atthe receiver's RDFI.

Traditionally, ACH operators include multiple mainframe processors,which process ACH files, file by file, on a first in, first out basis.Each ACH file is processed by a single one of the mainframe processors.Because each ACH file can include a varying number of batches with avarying number of transaction items, each mainframe processor can bear adifferent processing load. For example, one mainframe processor mayprocess an ACH file with only a single transaction item, while anothermainframe processor may process an ACH file with multiple batchesincluding large amounts of transaction items. Thus, at least somemainframe processors may be over-loaded or under-loaded. This results inmany processing inefficiencies, including ineffective use of theunder-loaded mainframe processors and delays in processing oftransaction items handled by the over-loaded mainframe processors.

Therefore, a need exists in the art for a system and method forefficiently processing ACH payments.

SUMMARY

The invention provides systems and methods for processing ACH payments.In particular, the invention provides systems and methods forefficiently processing ACH payments by processing batches of ACHpayments in parallel.

An ACH processing system of an ACH operator receives an ACH fileincluding multiple batches of ACH items. For example, the ACH processingsystem can receive the ACH file from an ODFI or an operator acting onbehalf of an ODFI. Each batch of the ACH file includes at least one ACHitem.

A control module of the ACH processing system organizes data in the ACHfile into multiple partitions according to a selected strategy. Eachpartition includes at least one of the batches. For example, the controlmodule can select a strategy that assigns (a) a fixed number of thebatches to each partition, (b) a substantially equal number of batchesto each partition, or (c) a substantially equal number of ACH items toeach partition. Other strategies for organizing batched data are wellknown to a person of ordinary skill in the art having the benefit of thepresent disclosure.

A processing module of the ACH processing system separately processeseach partition in parallel. For example, each of multiple processorsassociated with the processing module can process at least one of thepartitions. Alternatively, multiple of the partitions may be processedon the same processor using application threading. For example, theprocessing module can utilize one or more java objects, such as IBMWebSphere Application Server's “asynchronous beans” running on a Java 2Platform Enterprise Edition (“J2EE”) application, to perform theapplication threading. The processing module can modify threadingparameters in the J2EE application to ensure that each processor is notover-loaded or under-loaded during processing.

During processing, the processing module validates the batches and ACHitems and creates at least one output batch for each partition. Eachoutput batch includes information regarding at least one of the ACHitems. For example, a particular output batch can include multiple ACHitems associated with the same ODFI and/or RDFI. The processing modulealso may store settlement information for each ACH item.

The output batches can include ACH items that were successfullyvalidated during processing or ACH items that were not successfullyvalidated during processing. For example, “risk pended” output batchescan include information regarding ACH items that were not successfullyvalidated during processing, and non-risk pended output batches caninclude information regarding ACH items that were successfully validatedduring processing.

The control module evaluates the validation results for each partitionto determine whether the ACH file is acceptable. If the control moduledetermines that the ACH file is not acceptable, then the ACH operatormay return the ACH file to the ODFI, suspend processing of the ACH file,and/or output a notification advising the ODFI and/or an operator of theACH processing system that the ACH file will not be processed. If thecontrol module determines that the ACH file is acceptable, then theprocessing module determines whether each output batch is a risk pendedoutput batch or a non-risk pended output batch. The processing modulesettles the ACH items in the non-risk pended output batches and createsat least one new ACH file for transmitting the settled ACH items to atleast one corresponding RDFI.

The processing module determines whether each risk pended output batchis acceptable for transmission to an RDFI. For example, the processingmodule can make that determination based on information from one or moreoperators of the ACH processing system and/or the ODFI. If theprocessing module determines that a particular risk pended output batchis not acceptable for transmission to an RDFI, then the ACH operator mayreturn the output batch and/or the ACH items contained therein to theODFI, suspend processing of the output batch and/or ACH items, and/oroutput a notification advising the ODFI and/or an operator of the ACHprocessing system that the output batch and/or ACH items will not beprocessed. If the processing module determines that the risk pendedoutput batch is acceptable for transmission to an RDFI, then theprocessing module settles the ACH items in the risk pended output batchand creates at least one new ACH file for transmitting the settled ACHitems to at least one corresponding RDFI.

Additional aspects, features, and advantages of the invention willbecome apparent to those skilled in the art upon consideration of thefollowing detailed description of illustrated embodiments exemplifyingthe best mode of carrying out the invention as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for efficiently processingan ACH file, in accordance with certain exemplary embodiments.

FIG. 2 is a flow chart depicting a method for efficiently processing anACH file, in accordance with certain exemplary embodiments.

FIG. 3 is a flow chart depicting a method for separately processingpartitions of an ACH file in parallel, in accordance with certainexemplary embodiments.

FIG. 4 is a flow chart depicting a method for processing risk pendedoutput batches, in accordance with certain exemplary embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The invention is directed to systems and methods for efficientlyprocessing ACH payments. In particular, the invention is directed tosystems and methods for efficiently processing ACH files by processingbatches of ACH payments in parallel.

The invention includes a computer program that embodies the functionsdescribed herein and illustrated in the appended flow charts. However,it should be apparent that there could be many different ways ofimplementing the invention in computer programming, and the inventionshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosed inventionbased on the flow charts and associated description in the applicationtext. Therefore, disclosure of a particular set of program codeinstructions is not considered necessary for an adequate understandingof how to make and use the invention. The inventive functionality of theclaimed computer program will be explained in more detail in thefollowing description read in conjunction with the figures illustratingthe program flow.

Turning now to the drawings, in which like numerals indicate likeelements throughout the figures, exemplary embodiments of the inventionare described in detail.

FIG. 1 is a block diagram depicting a system 100 for efficientlyprocessing an ACH file, in accordance with certain exemplaryembodiments. The system 100 is described below with reference to themethods illustrated in FIGS. 2-4.

FIG. 2 is a flow chart depicting a method 200 for efficiently processingan ACH file, in accordance with certain exemplary embodiments. Theexemplary method 200 is illustrative and, in alternative embodiments ofthe invention, certain steps can be performed in a different order, inparallel with one another, or omitted entirely, and/or certainadditional steps can be performed without departing from the scope andspirit of the invention. The method 200 is described below withreference to FIGS. 1 and 2.

In step 205, an ACH operator 105 receives an ACH file including multiplebatches of ACH items. The ACH operator 105 is a Federal Reserve Bank orother entity that receives an ACH file from an originating depositoryfinancial institution 102 (“ODFI”) and distributes transaction itemswithin the ACH file to at least one corresponding receiving depositoryfinancial institution 115 (“RDFI”). In some cases, the ACH operator 105also may perform settlement functions (crediting and debiting ofaccounts) for the affected financial institutions 102, 115.

In certain alternative exemplary embodiments, the ACH operator 105 canreceive the ACH file from a third party or “remote” sending point (notshown) operating on behalf of the ODFI 102. The third party or remotesending point may be a depository financial institution or a companyproviding processing services for a depository financial institution.The term “ACH file” is used herein to refer to any collection of batchedand/or unbatched ACH items.

In certain exemplary embodiments, the ACH operator 105 can receive theACH file via a network 104. The network 104 can include any wired orwireless telecommunication means by which computerized devices canexchange data, including for example, a local area network (LAN), a widearea network (WAN), an intranet, an Internet, or any combinationthereof. For example, the network 104 can include the ACH network.

Each batch of the received ACH file includes one or more transactionitems. The terms “transaction item” and “ACH item” are usedinterchangeably herein to refer to any batched electronic payment orpayment instruction, whether international or domestic, and/orinformation associated with a batched electronic payment or paymentinstruction. For example, a payment or payment instruction can be acredit, a debit, or a rejected or returned transaction.

In step 210, a processing module 107 of a processing system 103 operatedby the ACH operator 105 performs a preliminary validation of the ACHfile. For example, the processing module 107 can determine whether thefile is properly formatted and/or includes suitable information forprocessing. In certain exemplary embodiments, the processing module 107can perform this preliminary validation based on one or more rulesstored in a database 109 of the processing system 103.

In step 215, the processing module 107 determines whether to process theACH file. For example, the processing module 107 can determine toprocess the ACH file if the ACH file is successfully validated in step210. Similarly, the processing module 107 can determine to not processthe ACH file if the ACH file is not successfully validated in step 210.

If the processing module 107 determines in step 215 to not process theACH file, then the method 200 branches to step 245, which is discussedbelow. If the processing module 107 determines in step 215 to processthe ACH file, then the method 200 continues to step 220.

In step 220, a control module 108 of the processing system 103 selects apartition strategy. The partition strategy is a schema for dividinginformation within the ACH file into multiple partitions. Each partitionincludes one or more of the batches of the ACH file.

For example, one partition strategy can be to assign a fixed number ofbatches to each partition. A second partition strategy can be to assignsubstantially equal numbers of batches to each of the partitions. Athird partition strategy can be to assign batches to the partitions sothat each partition includes a substantially equal number of ACH items.A person of ordinary skill in the art having the benefit of the presentdisclosure will recognize that many other strategies exist forpartitioning batches of data.

In step 225, the control module 108 organizes the data in the ACH fileinto multiple partitions according to the strategy selected in step 220.In step 230, the processing module 107 separately processes eachpartition in parallel. For example, each of multiple processors (notshown) associated with the processing module 107 can process at leastone of the partitions. Alternatively, multiple of the partitions may beprocessed on the same processor using application threading. Forexample, in certain exemplary embodiments, the processing module 107 canutilize one or more java objects, such as asynchronous beans running ona Java 2 Platform Enterprise Edition (“J2EE”) application, to performthe application threading. In certain exemplary embodiments, theprocessing module 107 can modify threading parameters in the J2EEapplication to ensure that each processor is not over-loaded orunder-loaded during processing.

During processing, the processing module 107 validates each batch andACH item and creates and stores output batches and settlementinformation for the ACH items. For example, the processing module 107can store the output batches and settlement information in the database109. Each output batch includes one or more ACH items. For example, allthe ACH items in a particular output batch can be associated with thesame RDFI 115 and/or ODFI 102. The processing module 107 can use theoutput batches and settlement information to complete the processing ofthe ACH items, as described below. In certain exemplary embodiments, theprocessing module 107 can store validation information, such asvalidation results, for each batch and ACH item in the database 109 ofthe processing system 103. Step 230 is described in more detail below,with reference to FIG. 3.

In step 235, the control module 108 reads validation informationassociated with each partition. For example, the control module 108 canread the validation information from the database 109 of the processingsystem 103. In step 240, the control module 108 determines whether theACH file is acceptable, based on the validation information read in step235. For example, the control module 108 may determine that an ACH fileis not acceptable if a large quantity of validation errors wereidentified in step 235. The control module 108 also may determine thatan ACH file is not acceptable if one or more significant validationerrors were identified in step 235. In certain exemplary embodiments,the processing module 107 can make the decision of step 240 based on oneor more rules stored in the database 109. In some cases, the controlmodule 108 may determine that an ACH file is not acceptable even if theACH file successfully completed the preliminary validation of step 215.

If the control module 108 determines in step 240 that the ACH file isnot acceptable, then the method 200 branches to step 245. In step 245,the control module 108 rejects the ACH file for further processing. Forexample, the control module 108 can return the ACH file to the ODFI 102via the network 104, suspend processing of the ACH file, and/or output anotification advising the ODFI 102 and/or an operator of the ACHprocessing system 103 that the ACH file will not be processed. Incertain exemplary embodiments, the ODFI 102 and/or operator can overridethe rejection decision if it determines that the ACH file actuallyshould be processed.

If the control module 108 determines in step 240 that the ACH file isacceptable, then the method 200 continues to step 246. In step 246, theprocessing module 107 determines whether each output batch (stored instep 230) is a “risk pended” output batch or a non-risk pended outputbatch. A risk pended output batch is an electronic file or record thatincludes information regarding at least one ACH item that was notsuccessfully validated (in step 230). Similarly, a non-risk pendedoutput batch is an electronic file or record that includes informationregarding at least one ACH item that has been successfully validated (instep 230). In certain exemplary embodiments, a “flag” or indicatorwithin, or associated with, a particular output batch can indicatewhether the output batch is a risk pended output batch or a non-riskpended output batch.

In step 250, the processing module 107 settles each ACH item in thenon-risk pended output batches using the settlement information storedin step 230. For example, the processing module 107 can cause accountsassociated with the ODFI 102 and RDFI 115 associated with each ACH itemto be credited and/or debited in accordance with the settlementinformation.

In step 255, the processing module 107 creates at least one new ACHfile. Each ACH file includes information regarding at least one of theACH items settled in step 250. For example, each ACH file can includeone or more of the non-risk pended output batches.

In certain exemplary embodiments, the processing module 107 can createat least one new ACH file for each RDFI 115. Each ACH file for aparticular RDFI 115 can include one or more batches of ACH itemsassociated with the RDFI 115. In step 260, the processing module 107transmits each new ACH file to its corresponding RDFI 115. For example,the processing module 107 can transmit the new ACH file(s) via thenetwork 104.

In step 265, the processing module 107 determines whether any riskpended output batches were identified in step 246. If so, then themethod 200 branches to step 270, which is described below with referenceto FIG. 4. If the processing module 107 determines that there were notany risk pended output batches identified in step 246, then the method200 ends.

FIG. 3 is a flow chart depicting a method 230 for separately processingpartitions of an ACH file in parallel, in accordance with certainexemplary embodiments, as referred to in step 230 of FIG. 2. Theexemplary method 230 is illustrative and, in alternative embodiments ofthe invention, certain steps can be performed in a different order, inparallel with one another, or omitted entirely, and/or certainadditional steps can be performed without departing from the scope andspirit of the invention. The method 230 is described below withreference to FIGS. 1-3.

The processing module 107 typically performs multiple instances of themethod 230 in parallel, with each instance being associated with adifferent one of the partitions of the ACH file. In step 305, theprocessing module 107 selects a batch of the partition. In step 310, theprocessing module 107 validates the batch and stores validation resultsin the database 109. For example, the processing module 107 can validatethe batch by determining whether the batch is properly formatted and/orincludes suitable information for processing. In certain exemplaryembodiments, the processing module 107 can perform this validation basedon one or more rules stored in the database 109. For example, the storedvalidation results can include information regarding any validationerrors identified during validation and/or information indicating thatthe batch was successfully validated, if appropriate.

In step 315, the processing module 107 determines whether the batch isacceptable, based on the validation performed in step 310. In certainexemplary embodiments, the processing module 107 can make the decisionof step 315 based on one or more rules stored in the database 109. Ifthe processing module 107 determines in step 315 that the batch is notacceptable, then the method 230 branches to step 330, which is discussedbelow.

If the processing module 107 determines in step 315 that the batch isacceptable, then the method 230 continues to step 320. In step 320, theprocessing module 107 validates ACH items in the batch and storesvalidation results in the database 109. For example, the processingmodule 107 can validate each ACH item by determining whether the ACHitem is properly formatted and/or includes suitable information forprocessing. In certain exemplary embodiments, the processing module 107can perform this validation based on one or more rules stored in thedatabase 109. For example, the stored validation results can includeinformation regarding any validation errors identified during validationand/or information identifying each successfully validated ACH item.

In step 325, the processing module 107 creates one or more outputbatches. Each output batch is an electronic file or record that includesinformation regarding at least one ACH item of the partition. Forexample, all the ACH items in a particular output batch can beassociated with the same RDFI 115 and/or ODFI 102.

In certain exemplary embodiments, the processing module 107 can create“risk pended” and “non-risk pended” output batches. A risk pended outputbatch is an electronic file or record that includes informationregarding at least one ACH item that was not successfully validated.Similarly, a non-risk pended output batch is an electronic file orrecord that includes information regarding at least one ACH item thathas been successfully validated. In certain exemplary embodiments, a“flag” or indicator within, or associated with, a particular outputbatch can indicate whether the output batch is a risk pended outputbatch or a non-risk pended output batch.

In step 330, the processing module 107 stores the output batches in thedatabase 109. In step 335, the processing module 107 determines whetherto select another batch. If so, then the method 230 branches back tostep 305 to repeat steps 305-330 for another batch. If the processingmodule 107 determines in step 335 to not select another batch, then themethod 230 continues to step 340.

In step 340, the processing module 107 stores settlement information foreach of the output batches in the database 109. For example, thesettlement information may include information useful in settlingpayment of each ACH item included in the output batches, such as anaggregate credit or debit amount for each ODFI 102 and/or RDFI 115, acredit or debit amount for each ACH item, an American BankersAssociation (“ABA”) number associated with each ODFI 102, and/or an ABAnumber associated with each RDFI 115. The method 230 continues to step235 of FIG. 2, discussed above.

FIG. 4 is a flow chart depicting a method 270 for processing risk pendedoutput batches, in accordance with certain exemplary embodiments, asreferred to in step 270 of FIG. 2. The exemplary method 270 isillustrative and, in alternative embodiments of the invention, certainsteps can be performed in a different order, in parallel with oneanother, or omitted entirely, and/or certain additional steps can beperformed without departing from the scope and spirit of the invention.The method 270 is described below with reference to FIGS. 1-4.

In step 405, the processing module identifies at least one risk pendedoutput batch. In step 410, the processing module determines whether eachidentified risk pended output batch risk is acceptable for transmissionto an RDFI 115. In certain exemplary embodiments, the processing module107 can make that determination based on information from one or moreoperators of the ACH processing system 103 and/or the ODFI 102. Forexample, the processing module 107 can transmit at least a portion ofeach risk pended output batch to its corresponding ODFI 102 for review,via the network 104. The operator(s) of the ODFI 102 and/or ACHprocessing system 103 can evaluate whether each risk pended output batchis suitable for transmission to the RDFI 115 based on one or more rules.For example, the rules may include certain formatting and/or contentrequirements for each batch and/or ACH item therein. The rules may bethe same or different from rules used in validating the ACH file,partitions, and ACH items in steps 210 and 230 of FIG. 2. In certainexemplary embodiments, the rules can be stored in a database, such asthe database 109.

In step 415, the processing module 107 rejects any risk pended ACH itemsdetermined in step 410 to not be acceptable for transmission. Forexample, the processing module 107 can return each rejected outputand/or the ACH items contained therein to its corresponding ODFI 102,suspend processing of the output batch and/or ACH items, and/or output anotification advising the ODFI 102 and/or an operator of the ACHprocessing system 103 that the output batch and/or ACH items will not beprocessed.

In step 420, the processing module 107 settles each ACH item in eachrisk pended output batch, if any, determined in step 410 to beacceptable for transmission. For example, the processing module 107 cancause accounts associated with the ODFI 102 and RDFI 115 of each ACHitem to be credited and/or debited in accordance with information in theACH item. Similar to step 255 of FIG. 2, in step 425, the processingmodule 107 creates at least one new ACH file for each RDFI 115associated with one or more of the ACH items settled in step 420. Eachnew ACH file for a particular RDFI 115 includes one or more batches ofacceptable ACH items associated with the RDFI 115. In step 430, theprocessing module 107 transmits each new ACH file to its correspondingRDFI 115. For example, the processing module 107 can transmit the newACH file(s) via the network 104.

It will be appreciated that the exemplary embodiments of the inventionovercome the limitations of the prior art. From the description of theexemplary embodiments, equivalents of the elements shown therein andways of constructing other embodiments of the invention will be apparentto practitioners of the art. Many other modifications, features andembodiments of the invention will become evident to those of skill inthe art. It should be appreciated, therefore, that many aspects of theinvention were described above by way of example only and are notintended as required or essential elements of the invention unlessexplicitly stated otherwise. Accordingly, it should be understood thatthe foregoing relates only to certain embodiments of the invention andthat numerous changes can be made therein without departing from thespirit and scope of the invention.

1. A computer-implemented method for processing automated clearinghouse(“ACH”) payments, comprising the steps of: receiving an ACH filecomprising a plurality of batches of ACH items, each of the batchescomprising at least one of the ACH items; organizing data in the ACHfile into a plurality of partitions, each partition comprising at leastone of the batches; and separately processing each partition in parallelto generate at least one new batch.
 2. The computer-implemented methodof claim 1, wherein the step of organizing data in the ACH filecomprises the steps of: selecting a strategy for organizing data in theACH file; and organizing data in the ACH file into the plurality ofpartitions according to the selected strategy.
 3. Thecomputer-implemented method of claim 1, wherein the step of organizingdata in the ACH file comprises the step of assigning a fixed number ofthe batches to each of the partitions.
 4. The computer-implementedmethod of claim 1, wherein the step of organizing data in the ACH filecomprises the step of assigning a substantially equal number of batchesto each of the partitions.
 5. The computer-implemented method of claim1, wherein the step of organizing data in the ACH file comprises thestep of assigning a substantially equal number of ACH items to each ofthe partitions.
 6. The computer-implemented method of claim 1, whereinthe step of separately processing each partition in parallel comprisesthe step of storing at least one new batch for each partition, each newbatch comprising information regarding at least one ACH item from thenew batch's partition.
 7. The computer-implemented method of claim 1,wherein the step of separately processing each partition in parallelcomprises the step of storing settlement information for each partition.8. The computer-implemented method of claim 1, wherein the step ofseparately processing each partition in parallel comprises the steps of:for each partition, determining whether each ACH item of the partitionis suitable for processing; and creating at least one new batch inresponse to determining that any ACH item of the partition is suitablefor processing, each new batch comprising at least one ACH item.
 9. Thecomputer-implemented method of claim 8, further comprising the steps of:determining whether the ACH file is suitable for processing based onwhether the ACH items of the partitions were determined to be suitablefor processing; and creating at least one new ACH file in response todetermining that the ACH file is suitable for processing, each new ACHfile comprising information regarding at least one of the at least onenew batch.
 10. The computer-implemented method of claim 9, furthercomprising the step of transmitting each new ACH file to a correspondingreceiving depository financial institution.
 11. A computer-implementedmethod for processing automated clearinghouse (“ACH”) payments,comprising the steps of: receiving an ACH file comprising a plurality ofbatches of ACH items, each of the batches comprising at least one of theACH items; selecting a strategy for organizing data in the ACH file intoa plurality of partitions, each partition comprising at least one of thebatches, the strategy comprising one of assigning a fixed number of thebatches to each of the partitions, assigning a substantially equalnumber of batches to each of the partitions, and assigning asubstantially equal number of ACH items to each of the partitions;organizing data in the ACH file into the plurality of partitionsaccording to the selected strategy; and separately processing eachpartition in parallel to generate at least one new batch.
 12. Thecomputer-implemented method of claim 11, wherein the step of separatelyprocessing each partition in parallel comprises the step of storing atleast one new batch for each partition, each new batch comprisinginformation regarding at least one ACH item from the new batch'spartition.
 13. The computer-implemented method of claim 11, wherein thestep of separately processing each partition in parallel comprises thestep of storing settlement information for each partition.
 14. Thecomputer-implemented method of claim 11, wherein the step of separatelyprocessing each partition in parallel comprises the steps of: for eachpartition, determining whether each ACH item of the partition issuitable for processing; and creating at least new batch in response todetermining that any ACH item of the partition is suitable forprocessing, each new batch comprising at least one ACH item.
 15. Thecomputer-implemented method of claim 14, further comprising the stepsof: determining whether the ACH file is suitable for processing based onwhether the ACH items of the partitions were determined to be suitablefor processing; and creating at least one new ACH file in response todetermining that the ACH file is suitable for processing, each new ACHfile comprising information regarding at least one of the at least onenew batch.
 16. The computer-implemented method of claim 15, furthercomprising the step of transmitting each new ACH file to a correspondingreceiving depository financial institution.
 17. A computer-implementedmethod for processing automated clearinghouse (“ACH”) payments,comprising the steps of: receiving an ACH file comprising a plurality ofbatches of ACH items, each of the batches comprising at least one of theACH items; organizing data in the ACH file into a plurality ofpartitions, each partition comprising at least one of the batches;separately processing each partition in parallel by storing at least onenew batch for each partition, each new batch comprising informationregarding at least one successfully validated ACH item from the newbatch's partition; and determining whether the ACH file is suitable forprocessing based on validation information associated with eachpartition; and creating at least one new ACH file in response todetermining that the ACH file is suitable for processing, each new ACHfile comprising information regarding at least one of the at least onenew batches.
 18. The computer-implemented method of claim 17, whereinthe step of organizing data in the ACH file comprises the steps of:selecting a strategy for organizing data in the ACH file into theplurality of partitions, each partition comprising at least one of thebatches, the strategy comprising one of assigning a fixed number of thebatches to each of the partitions, assigning a substantially equalnumber of batches to each of the partitions, and assigning asubstantially equal number of ACH items to each of the partitions; andorganizing data in the ACH file into the plurality of partitionsaccording to the selected strategy.
 19. The computer-implemented methodof claim 17, wherein the step of separately processing each partition inparallel further comprises the step of storing settlement informationfor each partition, the stored settlement information for each of thepartitions comprising information regarding at least one successfullyvalidated ACH item from the partition.
 20. The computer-implementedmethod of claim 17, further comprising the step of transmitting each newACH file to a corresponding receiving depository financial institution.